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(54) lUiethod of securely loading commands in a smart card 

(57) The invention relates to a method of securely 
loading and validating commands (COM) in a smart 
card (SC). Especially in the case where application-spe- 
cific commands are loaded by an application provider 
(AP), that is off-line \vith respect to the card issuer (CI), 
it must be ensured that the commands are valid. The 
invention provides a method involving the protection of 
the commands (COM) by means of authentication 
codes, these codes (MACI, MAC2) being produced 
using two different keys: one key (K1) is stored by the 
card issuer (CI), the other (K2) by a trusted third party 
(TTP). A further authentication code (MACS), produced 
using a key from a set of keys (K3*). may be utilized to 
selectively validate commands for indivklual applica- 
tions (e.g. API, AP2). 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to a method of load- s 
ing commands in a smart card. More specifically, the 
present invention relates to a method of off-line loading 
application specific commands in a snrart card. 

In modern payment systems, the use of electronic 
payment means becomes increasingly important Elec- io 
tronic payment means, such as memory cards and 
smart cards, are gaining acceptance as their af^lica- 
tions are expanded. In many contries electronic cards 
are being used for public telephones an6 the like. 
Advanced cards are capable of containing electronic is 
"purses**, in addition to other functionalities. Such 
advanced payment means contain, in addition to a 
memory, a processor capable of running suitable pro- 
grams. 

It should be noted that in this text, the terms smart 20 
card or card will be used to denote electronic payment 
means having at least one integrated electronic circuit 
comprising a processor and a memory. The actual 
shape of a so-called smart card is not of importance. 

The progran^ running on the processor of a smart 2S 
card determine the services offered by the card, that is. 
the functions and assodated data structures (e.g. 
purse, user Identification, loyalty program) of the smart 
card depend on the software present in the card. As 
time passes, the need often arises to update the pro- 30 
grams of the card, for example in order to add a new 
function or to improve an existing function. To this end, 
the card should be able to accept new programs which 
may replace other programs. However, it must be ascer- 
tained that the newly loaded programs are valid. 35 

Authentication of programs can relatively easily be 
accomplished by using a secure data exchange proto- 
col between the card Issuer arKl the card. However, 
other parties, such as applications providers, want to be 
atiie to load new applications (arxi hence new com- 40 
nr^nds) into a card without having to do this via the card 
issuer. 

SUMMARY OF THE INVENTION 

45 

It is an object of the invention to overcome the 
above-mentioned and other disadvantages and to pro- 
vide a method which allows commands to be loaded 
and activated in a smart card in a secure manner. It is a 
further object of the present invention to provide a so 
method which allows application-specific commands to 
be loaded in a smart card by an application provider 
while being able to guararrtee the integrity of the com- 
mands. 

These and other objects are achieved by a method ss 
of securely loading commands in a snr^ card by a first 
party, the card being issued by a second party, the 
method according to the invention comprising the steps 
of: 



the second party producing a first authentication 

code of a command using a first key. 

a third party producing a second authentication 

code of the command using a second key. 

transferring the command with the codes to the 

card, 

the card validating the command by reproducing 
the first and second authentcation codes using the 
first and the second key respectively and compar- 
ing the r^roduced codes with the transferred 
codes. 

In the method of the present invention, the authen- 
ticity of the commands is thus safeguarded by having 
two different and preferably ind^endent parties pro- 
duce an authentication code: the secorKl party, which 
normally is the card issuer, and a third party, which nor- 
mally is a trusted independent party, such as a central 
bank. Once both authentication codes have been pro- 
duced, it is virtually impossible to alter the commands 
without this being noticeable by means of the authenti- 
cation codes. The first party, the application provider, 
has proof that both the first and second parties have 
"certified" the command. Preferatrfy the third party 
stores copies of the command. 

It will be understood that the method of the inven- 
tion applies to both the loading of a single command 
and the loading of a set of commands. 

The transferring to the card and the subsequent val- 
kiation are preferatrfy repeated when the validation fails, 
the use of the loaded commarxis being blocked until the 
validation succeeds. This prevents invalid commarKis, 
i.e. commands affected by transmission errors or 
manipulations, to be executed by the card. 

Advantageously, the loaded commands are perma- 
nently disabled when the validation fails a predeter- 
mined number off times, the nurrtoer preferably being 
less than ten. The disabling of the loaded commands 
may be performed by changing the key of the second 
party. In this way. the indefinite reloading of corrupted 
commands can be terminated. 

The commands loaded may be application-specif fc 
commands, i.e. commands directly influencing the 
applications of the card. Such commands are often 
machine language instructions which in principle allow 
nnan'pulation of the card applications. By using the 
method of the present invention, the use of such com- 
nrtands is controlled whereby the integrity of the applica- 
tions is ensured. 

The first and/or second authentication codes are 
preferably message authentication codes produced 
according to the ANSI X9.19 standard. 

Advantageously, an additional authentication code 
is produced by the second party, said additional code 
not involving the first or second key. This allows the first 
party a validity check without influencing the metiiod as 
such. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Rg. 1 shows a smart card as may be used in the 
method of the present invention. 

Fig. 2 schematically shows the integrated circuit of 
the smart card of Rg. 1 . 

Fig. 3 schematically shows the exchange of data in 
the method of the present Invention. 

Fig. 4 schematically shows data structures on a 
smart card. 

Fig. 5 schematically shows a flag register as used 
in the method of the present invention. 

Fig. 6 schematically shows an exemplary emtxxJi- 
ment of the method of the present invention. 

EXEMPLARY EMBODIMENTS 

The smart card or IC card 1 shown by way of exam- 
ple in Fig. 1 comprises a substrate 2, in which an inte- 
grated circuit is emt>edded. The integrated circuit is 
provided with contacts 3 for contacting a card reader or 
the like. It should be noted that the present invention 
can also be applied in the case of so-called contactiess 
smart cards. 

The integrated circuit 1 0 shown schematically and 
by way of exanrple in Rg. 2 comprises a processor 1 1 , 
a memory 12 and an input/output circuit 13. The mem- 
ory may comprise a volatile (RAM) memory part for 
tenrporarily storing data and a non-volatile (ROM) mem- 
ory part for permanently or semi-permanently storing 
data. The latter part is preferably an EEPROM type 
memory. The data stored in the non-volatile part may 
contain both programming data (instructions, progranis) 
and payment data, i.e. data relating to monetary trans- 
actions. It will be understood that a separate memory 
(rrot shown) may be provided to store the instruction set 
of the processor 11. The inixrt-output circuit 13 may 
communicate with external devices via contacts (not 
shown in Fig, 2), such as the contacts 3 shown in Fig. 1 . 
The integrated circuit 10 may be contained in the card 1 
of Rg. 1. 

An embodiment of the method according to the 
invention is shown schematically and by way of example 
in Rg. 3. A first party, e.g. an application provider AP. 
offers card functions to its customers. A smart card SC 
is issued by a second party, a card issuer CI. According 
to the invention, a trusted third party TTP is involved in 
the validation of commands, as will be explained later. 

A set of commands COM may have been produced 
by the card issuer CI or by an external source by order 
of the applications provider AR It should be noted that 
the set of commands COM may comprise one or more 
commands. That is, the method as described here may 
be applied to individual commands or to a set of com- 
mands. In the follovwng description, a single command 
rather than a set will be used as an exanrple to explain 
the method of the invention. The commands may be 
application-specific commands (ASC) or general pur- 
pose commands (GPC). 



As shown in Fig. 3, the application provider AP 
offers a command (COM) to the card issuer CI for 
authentication. A first authentication code MAC1, based 
on the command COM. is produced by the card issuer 

5 CI using a first key K1 . In addition to the code MAC1 the 
set of commancte may optionally receive an additional 
(fourth) authentication code MAC4 which does not 
involve the use of a key. at least not the key K1. The 
additional authentication code MAC4 serves to provide 

10 an additional verification of the command, independent 
of the keys used in the other authentication codes. The 
computation of the additional authentication code 
MAC4 may involve the first authentication code MACl. 
In that case, the additional authentication code can be 

IS written as: 

MAC4 = Fki(COM, MACl) , 
where F denotes a function by which the code is deter- 
mined. The authentication code MACl , and optionally 
the additional authentication code MAC4, is transferred 

20 to the application provider AP. where it is temporarily 
stored. 

According to the present invention, the command 
COM is also offered to a trusted third party TTP. The 
third party produces a second authentication code 

25 MAC2 of the command COM. using a second key K2. 
The second authentication code MAC2 is transferred to 
the application provider AP. The third party is e.g. a cen- 
tral bank or an institution appointed by the card issuer 
arxJ the service provider. 

30 The application provider AP nrray produce a third 
authentication code MAC3 using a third key K3*. It 
should be noted that the key K3* may conrprise a set of 
keys (as denoted by the asterisk), each individual key 
corresponding with an IrKiividual card application and/or 

35 individual card file. The key K3*. which may thus consist 
of a set of keys K3-1 , K3-2. etc., may be used to selec- 
tively load commands into specific applications and/or 
files of the card. This will further be explained with refer- 
ence to Figs. 4 and 5. It should be noted that as the third 

40 key (K3) may vary between applications, the third 
authentication code (MAC3) also varies. That is. the 
third authentication code (MAC3) may constitute an 
application-specific authentication code. It should be 
noted that the third authentication code may be based 

45 on both the command COM and tfie first and second 
authentication codes, thus providing a double authenti- 
cation. In tiiat case, tiie third authentication code can be 
written as: 

MACS = Fk3(COM. MACl , MAC2) . 

50 where F denotes a function by which the code is deter- 
mined. 

The authentication codes MACl and MAC2. as well 
as the authentication codes MAC3 and MAC4, are pref- 
erably produced using a message authemication 
55 scheme involving encryption. Such a scheme is e.g. dis- 
closed in the ANSI X9. 19 standard. It will be understood 
that the actual scheme (or schemes) used in producing 
the message authenticationxodes is not essential to the 
present invention. The additional atithentication code 
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may also be produced using encryption (e.g. using a 
public key), or may be produced using a so-called hash 
function. 

Both authentication codes MAC1 and MAC2, as 
well as the optional authentication codes MACS and 
MAC4. may be appended to the command, or be asso- 
ciated Nwith the command in another manner. In Fig. 3, 
the command and its associated authentication codes is 
dieted by: 

COM. MAC1 . MAC2 [ ,MAC3. MAC4] , 
the square brackets indicating the optional codes. The 
actual order In which the conrmand and its associated 
codes is transferred may of course vary. 

Upon receipt of the command by the card SC. the 
card reproduces the authentication codes MAC1 and 
MAC2 using the keys K1 and K2 which have been 
stored in the card previously. The reproduced codes 
MACV and MAC2' are compared with the received 
codes MAC1 and MAC2. If the reproduced and received 
codes are identical, the validation of the commands has 
succeeded and the commands may be activated. This 
activation may be done by setting (or resetting) a certain 
flag. If the validation fails, i.e. if the corresporxJing 
received and reproduced codes are not identical, a 
request for retrartsmission of the commands may be 
issued. A retransmission counter keeps track of the 
number of retransmissions and inhibits retransmission if 
a predetermined number (e.g. 5) is exceeded. 

The card is thus preferably arranged in such a way 
that the commarKis loaded into the card cannot be used 
until they are activated. That is. the loaded coninnands 
are blocked until they are released as a result of a posi- 
tive validation. This prevents irrvalid commands to be 
executed by the card. 

Fig. 4 schematically shews data structures on a 
smart card, such as the card 1 of Fig. 1. according to a 
preferred emtxxliment of the present invention. The 
data structures are in practice stored in a menrK>ry, such 
as the memory 12 of Rg. 2. 

A so-called nraster file MF contains, i.a.. references 
to other files. Other files are associated with individual 
applications. In Fig. 4. several so-called application files 
(API, AP2. APS) are shown. Each application (or appli- 
cation file) AP1. AP2 may comprise one or more 

subfiles, e.g. program files and data files. 

As shown in Rg. 4. each application contains a cor- 
responding key: application 1 contains key K3-1, appli- 
cation 2 contains key K3-2. etc. These keys K3-i 
correspond with the keys K3-i of the set of keys K3* of 
Fig. 3 (i denoting the i**^ application). As set out above, 
the card is able to regenerate authentication codes (e.g. 
MAC1 , MAC2) of a command, using one or more keys 
(e.g. K1 . K2), and to compare the regenerated codes 
(e-g. MAGI. MAC2) with the receved codes in order to 
verify the received command. That is, if the received 
and the regenerated authentication codes (&g. MAC2 
ar^ MAC2*) do not match, the corresponding command 
is not loaded into the card, or at least is baned from exe- 
cution. Similarly, the keys of the set K3* may be used to 



selectively load commands into individual applications, 
the target application (e.g. AP2) being indicated by the 
corresponding key (e.g. K3-2). In case a certain com- 
mand must be loaded into more than one application, 

5 the key K3 may contain a wildcard. 

As is illustrated in Fig. 4. the master file MF con- 
tains a flag register FR. In fig. 5. the flag register FR is 
rendered in more detail. The flag register FR comprises 
a plurality of flags F-1. F-2. ... of e.g. one bit each. Each 

10 flag corresponds with a command of the processor (1 1 
in Fig. 2) of the card. The processor and/or its software 
is arranged in such a way that the execution of a com- 
mand is inhibited if its corresponding flag is set. The 
UPDATE command, which updates a memory location. 

IS may e.g. only be executed if F-3 is set. Thus an addi- 
tional protection is provided against the unauthorized or 
inadvertent execution of (application specific) com- 
mands. 

The flag register can be controlled by a suitable 
20 command. e.g- SET_FLAG-i. where i is the flag number. 
If the commands concerned are application-specific 
commands, all flags are preferaWy initially set. thus pre- 
venting the execution of application-specific commands. 
A flag may be reset by a command-validating command 
25 (e.g. VALIDATE), i.e. if the authenticity of the command 
has been verified and the execution of the commarKi s 
allowed. It will be understood that the flag register FR 
may be located in other fnes that the master file MF. and 
that more than one flag register nr^y be contained in a 
30 card. 

The f tow diagram of Rg. 6 schematically shows an 
en±KxJiment of the method of the present invention. In 
step 100. the procedure is initialised. This may involve 
producing one or nrK^e commands arxJ offering the 

35 command to the application provider AP, who may in 
turn transfer the commarxJ to the card issuer CI and the 
third party TTP. 

In step 101, the card issuer CI produces a first 
authentication code MAC1 of the command (COM in 

40 Fig. 3) using the first key Kl. The code MACI is trans- 
ferred to the application provider AP. The command may 
have been transferred to the card issuer CI in step 101 
or previously, e.g. in step 100. 

Similarly, in step 102. the third party TTP produces 

45 a second authentication code MAC2 of the command 
(COM in Rg. 3) using the second key K2. The code 
MAC2 is transferred to the application provider AP. The 
command may have been transferred to the third party 
in step 102 or previously, e.g. in step 100. 

so In step 103. the application provider AP transfers 
the command COM with the associated authentication 
codes MACI and MAC2 to the smart card SC (cf. Rg. 
3). In step 104. the smart card SC essentially repro- 
duces the codes MACI and MAC2 by producing 

55 authentication codes MACV and MAC2* of the com- 
mand COM. using the keys Kl and K2 respectively. In 
step 105. the reproduced code MACI* is compared with 
the received code MACI . If the codes are equal, control 
is transferred to step 106. otherwise the procedure is 
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exrted. 

If the procedure is exited, the command COM 
received by the card is effectively inhibited^ either by 
erasing the command or by setting a flag in the flag reg- 
ister. A retransmission of the command COM and its 
associated authentication codes may be requested. 
Preferably the number of retransmissions is monitored 
and the retransmitting may be terminated if the number 
of attempts exceeds a predetermined number, e.g. 
three or five. 

In step 106. the reproduced code MAC2* is com- 
pared with the received code MAC2. If the codes are 
equal, control is transferred to step 107, otherwise the 
procedure is exited. 

In step 107. the smart card SC enat)les the com- 
mand COM. e.g. by resetting the corresponding flag In 
the flag register FR (cf. Rg. 5). The command COM may 
now be Invoked and executed. In step 108. the proce- 
dure Is terminated. 

In the diagram of Fig. 6. only the essential steps of 
a preferred embodiment have been shown. Additional 
steps, such as the determining and evaluating of the 
third and fourth authentication codes MAC3 and MAC4. 
have been omitted for the sake of clarity. It will thus be 
understood by those skilled in the art that the embodi- 
ments described above are given by way of example 
only and that many modifications and additions are pos- 
sible without departing from the scope of the present 
invention. 

Clainns 

1 . Method of securely loading commands (COM) in a 
smart card (SC) by a first party (AP). the card (SC) 
being issued by a second party (CI), the method 
comprising the steps of: 

the second party (CI) producing a first authen- 
tication code (MAC1) of a command using a 
first key (K1). 

a third party (TTP) producing a second authen- 
tication code (MAC2) of the command using a 
second key (K2). 

transferring the command (COM) with the 
codes (MAC1 . MAC2) to the card, 
the card (SC) validating the command (COM) 
by reproducing the first (MAC1) and second 
(MAC2) authentication codes using the first 
(K1) and the second (K2) key respectively and 
comparing the reproduced codes (MACV, 
MAC2') with the transferred codes (MAC1, 
MAC2). 

2. Method according to daim 1 , wherein the transfer- 
ring to tiie card (SC) and the subsequent validation 
are repeated when the validation fails, the use of 
the loaded command (COM) being blocked until the 
validation succeeds. 



3- Method according to claim 2. wherein the loaded 
command (COM) is permanently disatjied if the val- 
idation fails a predetermined nurrt>er (N) of times, 
the number (N) preferably being less than ten. 

5 

4. Method according to claim 3, wherein the disabling 
is performed by the card (1) changing the key (K1) 
of the second party (CI) stored in the card. 

10 5. Method according to any of the preceding claims, 
wherein the command (COM) is an application-spe- 
cific command (ASC). 

6. Method according to any of the prececfing claims, 
15 wherein the first (MACI) and/or second (MAC2) 
authentication codes are message authentication 
codes produced according to the ANSI X9.19 
standard. 

20 7. Method according to any of the prececfing claims, 
wherein the card contains several applications (e.g. 
API. AP2). each application being provided with an 
individual third key (e.g. K3-2) for validating a com- 
mand provided with a third authentication code 

25 (MACS), said third authentication code being pro- 
duced using the individual third key (K3-2). 

8. Method according to any of the prececfing clairrs. 
wherein the second party (CI) produces a fourth 

30 authentication code (MAC4) of the commarKJ 
(COM), said fourth code (MAC4) not involving the 
first (K1) or second (K2) key. 

9. Method according to any of the prececfing clainrs. 
35 wherein the card comprises a flag register (FR). 

each flag (F-1. F-2. ...) corresporxJing with a com- 
mand of tiie pr(x:essor (1 1 ), the execution of a com- 
mand being inhibited iff its flag (e.g. F-2) is set. 

40 10. Card (1), comprising a substrate (2) and an inte- 
grated circuit (10) having a processor (11) and a 
memory (12). the memory containing keys (e.g. K1 , 
K2), characterised in that the integrated circuit (10) 
is arranged to regenerate, using at least two keys 

45 (e.g. K1 , K2). autiientication codes (MACI , MAC2) 
of a received command (COM) and to compare 
regenerated authentication ccxies (MACV. MAC2*) 
with received authentic^ation cxxies (MACI, MAC2). 

so 11. Card according to claim 10, the memory (12) com- 
p-ising a data struc;ture having irxJividual applica- 
tions (e.g. API , AP2), each application containing 
an Individual key (e.g. K3-1, K3-2) for regenerating 
authentication ccxies and selectively loading com- 

55 mancjs associated with the authentication codes. 

12. Card accorcfing to claim 10 or 1 1. tiie memory (12) 
comprising a flag register (FR), each flag (F-1 . F-2, 
...) corresponding with a commahd of the processor 
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(11), the execution of a command being inhibited if 
its flag (e.g. F-2) is set 
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